Note that, due to the first commit, this still gives us all the benefits of #5249: if RUSTFLAGS is empty, we will run only a single rustc process, even if we can't cache it across different cargo invocations.
Auto merge of #5386 - ysimonson:new-metadata, r=matklad
Added new metadata fields
Addresses #5373.
`cargo metadata` should now include all of the non-optional suggested fields in the [API guidelines](https://rust-lang-nursery.github.io/api-guidelines/documentation.html#cargotoml-includes-all-common-metadata-c-metadata).
Auto merge of #5360 - euclio:metadata, r=alexcrichton
include package metadata in `cargo metadata`
Fixes #4819.
All-in-all a pretty small change. I'm a little concerned about threading the `toml::Value` all the way through however, should I make another type? Also, cloning the metadata value initially is maybe not ideal, since it's technically accessible through the original manifest. I figured this way was cleaner.
Auto merge of #5353 - matklad:features, r=alexcrichton
New semantics for `--features` flag
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
Auto merge of #5348 - djc:resolve-target-specific, r=alexcrichton
Have compilation context info available earlier in the build process
Eventually, I hope this will allow us to ignore platform-specific dependencies when irrelevant for the current build earlier in the process. This should save on extraneous errors. As is, this seems like it already decreases coupling in the code base.
Auto merge of #5323 - matklad:document-good-stuff, r=alexcrichton
Document how to use Cargo's internal logging
I always forget the syntax for filtering by module, and I've learned about `CARGO_PROFILE` yesterday, so let's document these for other contributors as well :-)
Auto merge of #5318 - ehuss:unstable-docs, r=matklad
Add unstable documentation.
I kept most of these relatively brief with the intent that more complete
documentation would be added when a feature is stabilized. I did my best to be
accurate, but I am unfamiliar with most of these features, so please let me know
if anything should change.
@matklad: I didn't fully understand the use case for `minimal-versions`, so I
didn't say much about it. In particular, I didn't understand why one wouldn't
just use `~` or `=` semver requirements if you wanted to be careful about not
pulling in a newer version. When someone says "1.0", aren't they explicitly
saying they want a newer version (up to 2.0) if it's available? The example
in the RFC of switching a dependency to "=1.0" sounds like a breaking change
(essentially downgrading a dependency).
Eric Huss [Sat, 7 Apr 2018 21:11:07 +0000 (14:11 -0700)]
Add unstable documentation.
I kept most of these relatively brief with the intent that more complete
documentation would be added when a feature is stabilized. I did my best to be
accurate, but I am unfamiliar with most of these features, so please let me know
if anything should change.
@matklad: I didn't fully understand the use case for `minimal-versions`, so I
didn't say much about it. In particular, I didn't understand why one wouldn't
just use `~` or `=` semver requirements if you wanted to be careful about not
pulling in a newer version. When someone says "1.0", aren't they explicitly
saying they want a newer version (up to 2.0) if it's available? The example
in the RFC of switching a dependency to "=1.0" sounds like a breaking change
(essentially downgrading a dependency).
projects / cargo.git / log